Congestion control is a well-known mechanism for controlling data entry into a communications network with communications links, or connections, between senders and receivers. Congestion control attempts to, among other things, avoid over-subscription of the link capacity so as to maintain the network performance at a satisfactory level. One of the typical measures used in congestion control is to regulate, or adjust, the rate of the data transmitted into the network by the individual senders. Usually, the regulation, or adjustment, takes into consideration certain feedback received from the receivers and/or any intermediate nodes along the connections.
Congestion control can be applied to all kinds of communications networks and implemented in many protocol stacks. For example, the Transmission Control Protocol, abbreviated as TCP, employs congestion control as one of its main aspects. TCP is an end-to-end protocol used for almost all data transmission over the Internet, such as HTTP, e-mail, file transfer and file download. TCP consists of a number of sub-systems of which congestion control is responsible for (fairly) utilising available bandwidth along the end-to-end connection.
There are many variants of congestion control, but most of them are based on the measurement of the transmission delay occurred on the connection between the two end-hosts. Such transmission delay is usually termed as Round Trip Time, abbreviated as RTT. Most congestion control variants use RTT measurements to detect how congested the network is.
Typically, an average of a certain number of instantaneous RTT measurements is calculated and maintained by the congestion control mechanism. Decisions as to data rate adjustments (e.g. whether to send more/less/no data into the network) are then based on this average and its derived statistical quantities.
As shown in FIG. 1, a typical TCP congestion control scenario, referred to as 100, attempts to predict or estimate future RTT's by sampling the behavior of data units, packets for example, sent over a connection and averaging the samples into a so-called “smoothed” Round Trip Time estimate, denoted as SRTT. The congestion control starts at step 102: When a plurality of packets is sent over a TCP connection, the receiver acknowledges the received packets by returning respective ACK messages. Then, at step 104, the sender measures the time it takes for the packets to be acknowledged by the receiver, producing a sequence of respective RTT samples: MRTT (1), MRTT (2), MRTT (3), and so on. Thereafter, as step 106 indicates, with each new sample MRTT (i), SRTT is updated according to the following:SRTT(i+1)=α×SRTT(i)+(1−α)×MRTT(i),  (1)where α is an adjustable constant between 0 and 1 that controls how rapidly SRTT adapts to changes. α can be expressed byα=(A−1)/A,  (2)where A is an arbitrarily chosen integer also termed “smoothing factor”. The larger the smoothing factor is, the more MRTT samples are needed in order to calculate the very first SRTT value, and naturally, the longer it takes to accumulate these MRTT samples. After the first SRTT value is obtained, SRTT is updated each time a new MRTT sample arrives. In many conventional implementations, A is set to 8.
Next, at step 108, from SRTT (i), a retransmission timeout, RTO, which indicates the amount of time the sender needs to wait for a given packet to be acknowledged, can be computed as follows:RTO(i)=β×SRTT(i)  (3)where β is another adjustable constant greater than 1. Typically, β is chosen such that there is a small probability that the Round Trip Time for the packet to be acknowledged (ACKed) should exceed RTO (i).
Finally, as step 110 shows, TCP congestion control uses certain algorithms to control the amount of outstanding data being injected into the network. Two common algorithms are “Slow Start” and “Congestion Avoidance”. To implement these algorithms, a TCP state variable, “Congestion Window” (cwnd), is added to the TCP per-connection state. The cwnd is a sender-side limit on the amount of data the sender can transmit into the network before receiving an acknowledgment (ACK). Another state variable, the “Slow Start Threshold” (ssthresh), is used to determine whether the slow start or congestion avoidance algorithm is used to control data transmission, as discussed below. Further, a “Sender Maximum Segment Size” (SMSS) is defined to indicate the size of the largest packet that the sender can transmit.
Beginning transmission into a network with unknown conditions requires TCP to slowly probe the network to determine the available capacity, in order to avoid congesting the network with an inappropriately large burst of data. The slow start algorithm is used for this purpose at the beginning of a transfer, or after repairing loss detected by the retransmission timer.
During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that acknowledges new data. Slow start ends when cwnd reaches or exceeds ssthresh or when congestion is observed. During congestion avoidance, cwnd is incremented by 1 full-sized segment per round-trip time (RTT). Congestion avoidance continues until congestion is detected.
Under normal conditions, an increase of the link capacity, e.g. bandwidth, causes the RTT to decrease. Particularly, sudden capacity increase on a bottleneck connection causes the RTT to swiftly decrease, as the bottleneck buffer empties. Thus, a decrease of RTT indicates an increased capacity that can be exploited. Inversely, an increase of RTT indicates a decrease of the connection capacity. However, none of the current congestion control mechanisms realises the usefulness of such indication and therefore has not implemented any measures to take advantage of it.
FIG. 2 shows how current TCP variants reach full connection utilisation after a large scale capacity increase. It can be seen that the adaptation from 10 Mbps to 100 Mbps—depending on network settings—takes between 10 to 50 seconds for high-speed TCP variants and more than 200 seconds for TCP NewReno. Further, it can be anticipated that, in certain communications technologies upcoming in the near future, e.g. in Long Term Evolution (LTE) systems, where the connection capacity is significantly larger than that of the current communications systems, the problem presented above will become even more relevant.